На днях появилась бета-версия продукта StarWind iSCSI SAN 5.9, средства номер 1 для создания отказоустойчивых хранилищ iSCSI под виртуальные машины VMware vSphere и Microsoft Hyper-V. Традиционно, несмотря на то что версия StarWind 5.8 вышла совсем недавно, нас ожидает множество нововведений и улучшений. Данная версия пока для VMware, под Hyper-V (Native SAN) выйдет немного позже.
Итак, новые возможности StarWind iSCSI 5.9, доступные в бете:
1. Трехузловой кластер высокой доступности хранилищ, еще больше повышающий надежность решения. При этом все три узла являются активными и на них идет запись. Диаграмма:
По обозначенным трем каналам синхронизации данные хранилищ синхронизируются между собой. Также все узлы обмениваются друг с другом сигналами доступности (Heartbeat).
2. Репликация на удаленный iSCSI Target через WAN-соединение с поддержкой дедупликации. Эта функция пока экспериментальная, но данная возомжность часто требуется заказчиками для катастрофоустойчивых решений хранилищ.
3. Поддержка механизмом дедупликации данных, которые удаляются с хранилищ - неиспользуемые блоки перезаписываются актуальными данными.
4. Использование памяти механизмом дедупликации сократилось на 30%. Теперь необходимо 2 МБ памяти на 1 ГБ дедуплицируемого хранилища при использовании блока дедупликациии 4 КБ.
5. StarWind SMI-S agent, доступный для загрузки как отдельный компонент. Он позволяет интегрировать StarWind в инфраструктуру Systme Center Virtual Machine Manager (SC VMM), добавив StarWind Storage Provider, реализующий задачи управления таргетами и хранилищами.
6. Как пишут на форуме, появилась полноценная поддержка механизма ALUA, работа с которым идет через SATP-плагин VMW_SATP_ALUA (подробнее об этом тут).
Скачать бета версию StarWind iSCSI SAN 5.9 можно по этой ссылке.
В преддверии выхода новой версии платформы для виртуализации настольных ПК VMware View 5.1, о котором будет объявлено 3 мая, продолжаем рассказывать о новых возможностях этого продукта. Сегодня продолжим разговор о функции Content Based Read Cache (CBRC), которая позволяет увеличить производительность операций чтения для наиболее часто читаемых блоков виртуальных ПК.
Как мы уже писали ранее, Content Based Read Cache - это функция кэширования в оперативной памяти хоста VMware ESXi, которая уже реализована в VMware vSphere 5. Убедиться в этом вы можете сами, открыв Advanced Settings на хосте:
Как мы видим из картинки, есть планка для CBRC размером в 2 ГБ, которую нельзя менять и есть текущее значение памяти, зарезервированной для кэша. Кроме того, есть настройка таймаута при загрузке хоста для дайджест-журнала SCSI, который хранит в себе хэш-таблицу блоков, которые учитывает кэш CBRC при их запросе от виртуальной машины.
Этот дайджест хранится в папке с виртуальной машиной в виде отдельного VMDK-файла:
То есть, при чтении виртуальной машиной блока с хранилища, он сначала ищется в кэше, и, если он там отсутствует, то он туда помещается и отдается виртуальной машине. Ну а если он в кэше есть - то сразу ей отдается. Соответственно, кэш CBRC увеличивает производительность при операциях чтения виртуальных машин хоста с одними и теми же блоками, что часто бывает в инфраструктуре VDI. Особенно это актуально при одновременной загрузке десятков виртуальных ПК, которая может вызвать так называемый Boot Storm. Посмотрите, как увеличивается интенсивность операций чтения при загрузке Windows ВМ, с которую может существенно "погасить" CBRC:
Надо отметить, что CBRC - это чисто хостовая фишка VMware vSphere, которую может поддерживать любое надстроенное VDI-решение (например, Citrix XenDesktop). А вот в VMware View поддержка CBRC будет идти под эгидой функции VMware View Storage Accelerator:
Как понятно из описанного выше, для такой поддержки практически ничего уже и делать не нужно - все есть в ESXi 5.0.
Во второй части заметки рассмотрим возможность VMware View Client Side Caching, которая представляет собой использование кэша в оперативной памяти устройств доступа к виртуальным ПК (тонкие и толстые клиенты с View Client) для картинки рабочего стола (а точнее, ее регионов). Эта возможность появилась уже в VMware View 5.0 и включена по умолчанию: 250 МБ памяти используется на клиенте, за исключением всяких Android и iOS-устройств.
Представьте, что вы просматриваете в виртуальном ПК PDF-документ. Рамка и контролы в ридере остаются на месте, а его содержимое скроллится в ограниченной области экрана. Вот для этого и нужен Client Side Caching - он позволяет закэшировать этот неизменяющийся фрагмент картинки экрана и не обращаться за ним к хосту и хранилищу. Это увеличивает производительность виртуального ПК до 30%.
Настраивается это просто - через шаблон групповой политики pcoip.adm, про работу с которым написано, например, вот тут. Настройка GPO называется "Configure PCoIP client image cache size policy":
Диапазон допустимых значений - от 50 до 300 МБ. Работает эта штука и для Linux-устройств. С ней есть тоже одна засада - если на тонком клиенте мало оперативной памяти (меньше 1 ГБ), клиентский кэш луше немного уменьшить, если наблюдаются проблемы с производительностью.
Подолжаем вас знакомить с решением номер 1 для создания отказоустойчивых хранилищ iSCSI серверов VMware ESXi и Microsoft Hyper-V - StarWind iSCSI. Как мы уже писали, недавно вышла новая версия StarWind Enterprise 5.8, предоставляющая еще больше возможностей для виртуальных машин, в частности, Hyper-V Backup Plugin и улучшения механизма дедупликации (полный список новинок).
Однако вышедший Microsoft Virtual Machine Converter - это единственное поддерживаемое со стороны MS решение для конверсии VMDK2VHD на платформу Hyper-V. Само собой, конвертируется не только виртуальный диск, но и вся машина в целом.
Конвертация виртуальной машины происходит с простоем ВМ, так как MVMC делает ее снапшот, сносит VMware Tools и драйверы, затем копирует исходный виртуальный диск, после чего откатывает снапшот ВМ.
Microsoft Virtual Machine Converter поддерживает V2V-конвертацию виртуальных машин со следующих платформ VMware:
VMware vSphere 5.0 (vCenter / ESX / ESXi 5.0)
VMware vSphere 4.1 (vCenter / ESX / ESXi 4.1)
В качестве хоста назначения могут быть использованы следующие платформы:
Windows Server 2008 R2 SP1 с ролью Hyper-V (+ Server Core)
Hyper-V Server 2008 R2 SP1
Для конвертации поддерживаются следующие гостевые ОС:
Windows Server 2003 SP2 Web, Standard, Enterprise и Datacenter (x86+x64)
Windows 7 Enterprise (x86+x64)
Windows Server 2008 R2 SP1 Web, Standard, Enterprise, Datacenter.
Поддержка семейства Windows Server 8 в бета-версии MVMC отсутствует. Документацию по Microsoft Virtual Machine Converter можно загрузить по этой ссылке. Тем, кому необходима P2V-миграция от Microsoft, следует использовать Microsoft P2V Migration Tool.
На блоге vMind.ru уже писали о просочившихся в интернет подробностях о новых возможностях решения для виртуализации настольных ПК VMware View 5.1, а мы сегодня осветим еще несколько интересных моментов.
Большинство нововведений VMware View 5.1 показаны на этом слайде:
Основная новая функция - это, конечно же, VMware View Storage Accelerator, которая позволяет использовать оперативную память сервера для кэширования наиболее часто используемых блоков данных виртуальных ПК, запрашиваемых с конечного устройства. Делается это средствами технологии Content Based Read Cache (CBRC), поддержка которой уже имеется в VMware vSphere 5.0. Эта штука, само собой, положительно влияет на скорость обмена данными с конечными устройствами и производительность операций ввода-вывода для виртуальных ПК, поскольку блоки запрашиваются напрямую из памяти:
Этот тест проводился для 50 виртуальных ПК с гостевой ОС Windows 7 и были достигнуты следующие результаты:
Увеличение до 80% пиковых IOPS
Увеличение на 45% средних IOPS
Увеличение пиковой скорости обмена с ПК до 65%
Увеличение средней скорости обмена с ПК на 25%
Настройки кэширования на хосте ESXi задаются в конфигурации VMware View Manager 5.1:
При этом, как и всегда, данная техника оптимизации полностью прозрачна для виртуальных машин, средств управления и прочего.
Полный список нововведений VMware View 5.1:
Расширенные техники по оптимизации хранилищ и интеграции с устройствами хранения:
View Storage Accelerator: использование локального кэша Content Based Read Cache (CBRC) на хосте vSphere 5.0
View Composer API Integration (находится в стадии Tech Preview): теперь операции по клонированию десктопов в View Composer используют технологию vStorage API for Array Integration (VAAI) Native Cloning для дисковых массивов NAS. Это позволит ускорить развертывание виртуальных ПК.
В View Composer можно будет задавать букву диска в гостевой ОС для disposable disk (своп и временные файлы)
Поддержка до 32-х (вместо 8) хостов в кластере, когда используется NAS-хранилище
Улучшенная поддержка USB-устройств, т.е. подключаемые к оконечному ПК устройства новых моделей (планшеты, камеры и т.п.) будут видны в виртуальном ПК
Поддержка двухфакторной аутентификации Radius
Улучшения административного интерфейса View Manager
Поддержка аккаунтов ПК в Active Directory, которые были созданы перед внедрением View
Программа VMware по улучшению качества работы в виртуальных ПК
Поддержка виртуальных профилей (Virtual Profiles) для физических ПК
Использование возможностей виртуальных профилей как средства миграции десктопа в виртуальную машину
Поддержка установки сервера View Composer на отличный от vCenter сервер
Теперь, что касается даты выхода VMware View 5.1. Анонсировано решение будет 2-3 мая (согласно информации CRN), а доступно для загрузки будет уже 9 мая. При этом VMware View 5.1 будет включать в себя vCenter Operations for View, который будет доступен как аддон за дополнительные деньги.
Ключевые особенности продукта от Symantec - возможность динамической балансировки запросов ввода-вывода с хоста по нескольким путям одновременно, поддержка работы с основными дисковыми массивами, представленными на рынке, и возможность учитывать характеристики хранилищ (RAID, SSD, Thin Provisioning).
Как можно узнать из нашей статьи про PSA, Veritas Dynamic Multi-Pathing (DMP) - это MPP-плагин для хостов ESXi:
Veritas DMP позволяет интеллектуально балансировать нагрузку с хостов ESXi в SAN, обеспечивать непрерывный мониторинг и статистику по путям в реальном времени, автоматически восстанавливать путь в случае сбоя и формировать отчетность через плагин к vCenter обо всех хранилищах в датацентре. Что самое интересное - это можно будет интегрировать с физическим ПО для доступа по нескольким путям (VxVM) в единой консоли.
Всего в Veritas DMP существует 7 политик для балансировки I/O-запросов, которые могут быть изменены "на лету" и позволят существенно оптимизировать канал доступа к хранилищу по сравнению со стандартным плагином PSP от VMware. Кстати, в терминологии Symantec, этот продукт называется - VxDMP.
Стоимость этой штуки - от 900 долларов за четырехъядерный процессор хоста (цена NAM). Полезные ссылки:
Мы недавно писали о новых возможностях продукта для создания отказоустойчивых iSCSI-хранилищ StarWind 5.8 (а тут можно почитать про производительность), а завтра вы можете лично убедиться в превосходстве StarWind над конкурентами и над тем, когда его у вас нет. Для этого завтра надо прийти на вебинар, тем более, что докладчик - наш с вами знакомый, Анатолий Вильчинский из Киева:
Как знают администраторы VMware vSphere в крупных компаниях, в этой платформе виртуализации есть фреймворк, называющийся VMware Pluggable Storage Architecture (PSA), который представляет собой модульную архитектуру работы с хранилищами SAN, позволяющую использовать ПО сторонних производителей для работы с дисковыми массивами и путями.
Выглядит это следующим образом:
А так понятнее:
Как видно из второй картинки, VMware PSA - это фреймворк, работа с которым происходит в слое VMkernel, отвечающем за работу с хранилищами. Расшифруем аббревиатуры:
VMware NMP - Native Multipathing Plug-In. Это стандартный модуль обработки ввода-вывода хоста по нескольким путям в SAN.
Third-party MPP - Multipathing plug-in. Это модуль стороннего производителя для работы по нескольким путям, например, EMC Powerpath
VMware SATP - Storage Array Type Plug-In. Это часть NMP от VMware (подмодуль), отвечающая за SCSI-операции с дисковым массивом конкретного производителя или локальным хранилищем.
VMware PSP - Path Selection Plug-In. Этот подмодуль NMP отвечает за выбор физического пути в SAN по запросу ввода-вывода от виртуальной машины.
Third-party SATP и PSP - это подмодули сторонних производителей, которые исполняют означенные выше функции и могут быть встроены в стандартный NMP от VMware.
MASK_PATH - это модуль, который позволяет маскировать LUN для хоста VMware ESX/ESXi. Более подробно о работе с ним и маскировании LUN через правила написано в KB 1009449.
Из этой же картинки мы можем заключить следующее: при выполнении команды ввода-вывода от виртуальной машины, VMkernel перенаправляет этот запрос либо к MPP, либо к NMP, в зависимости от установленного ПО и обращения к конкретной модели массива, а далее он уже проходит через подуровни SATP и PSP.
Уровень SATP
Это подмодули, которые обеспечивают работу с типами дисковых массивов с хоста ESXi. В составе ПО ESXi есть стандартный набор драйверов, которые есть под все типы дисковых массивов, поддерживаемых VMware (т.е. те, что есть в списке совместимости HCL). Кроме того, есть универсальные SATP для работы с дисковыми массивами Active-active и ALUA (где LUN'ом "владеет" один Storage Processor, SP).
Каждый SATP умеет "общаться" с дисковым массивом конкретного типа, чтобы определить состояние пути к SP, активировать или деактивировать путь. После того, как NMP выбрал нужный SATP для хранилища, он передает ему следующие функции:
Мониторинг состояния каждого из физических путей.
Оповещение об изменении состояний путей
Выполнение действий, необходимый для восстановления пути (например failover на резервный путь для active-passive массивов)
Посмотреть список загруженных SATP-подмодулей можно командой:
esxcli nmp satp list
Уровень PSP
Path Selection Plug-In отвечает за выбор физического пути для I/O запросов. Подмодуль SATP указывает PSP, какую политику путей выставить для данного типа массива, в зависимости от режима его работы (a-a или a-p). Вы можете переназначить эту политику через vSphere Client, выбрав пункт "Manage Paths" для устройства:
Для LUN, презентуемых с массивов Active-active, как правило, выбирается политика Fixed (preferred path), для массивов Active-passive используется дефолтная политика Most Recently Used (MRU). Есть также и еще 2 политики, о которых вы можете прочитать в KB 1011340. Например, политика Fixed path with Array Preference (VMW_PSP_FIXED_AP) по умолчанию выбирается для обоих типов массивов, которые поддерживают ALUA (EMC Clariion, HP EVA).
Надо отметить, что сторонний MPP может выбирать путь не только базовыми методами, как это делает VMware PSP, но и на базе статистического интеллектуального анализа загрузки по нескольким путям, что делает, например, ПО EMC Powerpath. На практике это может означать рост производительности доступа по нескольким путям даже в несколько раз.
Работа с фреймворком PSA
Существуют 3 основных команды для работы с фреймворком PSA:
esxcli, vicfg-mpath, vicfg-mpath35
Команды vicfg-mpath и vicfg-mpath35 аналогичны, просто последняя - используется для ESX 3.5. Общий список доступных путей и их статусы с информацией об устройствах можно вывести командой:
vicfg-mpath -l
Через пакет esxcli можно управлять путями и плагинами PSA через 2 основные команды: corestorage и nmp.
Надо отметить, что некоторые команды esxcli работают в интерактивном режиме. С помощью nmp можно вывести список активных правил для различных плагинов PSA (кликабельно):
esxcli corestorage claimrule list
Есть три типа правил: обычный multipathing - MP (слева), FILTER (аппаратное ускорение включено) и VAAI, когда вы работаете с массивом с поддержкой VAAI. Правила идут в порядке возрастания, с номера 0 до 101 они зарезервированы VMware, пользователь может выбирать номера от 102 до 60 000. Подробнее о работе с правилами можно прочитать вот тут.
Правила идут парами, где file обозначает, что правило определено, а runtime - что оно загружено. Да, кстати, для тех, кто не маскировал LUN с версии 3.5. Начиная с версии 4.0, маскировать LUN нужно не через настройки в vCenter на хостах, а через объявление правил для подмодуля MASK_PATH.
Для вывода информации об имеющихся LUN и их опциях в формате PSA можно воспользоваться командой:
esxcli nmp device list
Можно использовать всю ту же vicfg-mpath -l.
Ну а для вывода информации о подмодулях SATP (типы массивов) и PSP (доступные политики путей) можно использовать команды:
esxcli nmp satp list
esxcli nmp psp list
Ну а дальше уже изучайте, как там можно глубже копать. Рекомендуемые документы:
Как знают все администраторы VMware vSphere, виртуальный диск виртуальной машины представляется как минимум в виде двух файлов:
<имя ВМ>.vmdk - заголовочный, он же индексный, он же файл-дескриптор виртуальго диска, который содержит информацию о геометрии диска, его тип и другие метаданные
<имя ВМ>-flat.vmdk - непосредственно диск с данными ВМ
Практика показывает, что нередки ситуации, когда администраторы VMware vSphere теряют заголовочный файл VMDK по некоторым причинам, иногда необъяснимым, и остается только диск с данными ВМ (неудивительно, ведь в него идет запись, он залочен).
Ниже приведена краткая процедура по восстановлению дескрипторного VMDK-файла для существующего flat-VMDK, чтобы восстановить работоспособность виртуальной машины. Подробную инструкцию можно прочитать в KB 1002511.
Итак, для тех, кто любит смотреть видеоинструкции:
Для тех, кто не любит:
1. Определяем точный размер в байтах VMDK-диска с данными (чтобы геометрия нового созданного дескриптора ему соответствовала):
ls -l <имя диска>-flat.vmdk
2. Создаем новый виртуальный диск (цифры - это полученный размер в байтах, тип thin для экономии места, lsilogic - контроллер):
vmkfstools -c 4294967296 -a lsilogic -d thin temp.vmdk
3. Переименовываем дескрипторный VMDK-файл созданного диска в тот файл, который нам нужен для исходного диска. Удаляем только что созданный пустой диск данных, который уже не нужен (temp-flat.vmdk).
Схема очень проста - StarWind iSCSI можно использовать как для продуктивного хранилища, так и для хранилища резервных копий:
В документе рассматривается вариант использования отказоустойчивого iSCSI-хранилища StarWind в производственной среде, где применяются такие возможности StarWind как:
Снапшоты хранилищ
Дедупликация
Отказоустойчивая конфигурация из двух серверов хранения, обеспечивающая непрерывную работу виртуальных машин в случае отказа одного из них
Компания VMware 2 апреля выпустила клиент для своей новой платформы облачного хранения данных, который доступен для скачивания с Apple Store: VMware Octopus Client для iPad и iPhone.
Напомним, что VMware Project Octopus - это некий аналог Dropbox от VMware, предлагающий функции не только для хранения документов предприятий, но и функции совместной работы, а также имеющий встроенные средства обеспечения безопасности. Об этом проекте мы уже писали тут и тут.
Octopus будет интегрирован со следующими продуктами VMware: Zimbra Collaboration Server for Web-based applications (средства совместной работы), VMware View (использование общих данных в виртуальных ПК), VMware Horizon (управление данными приложений из корпоративного каталога) и AppBlast (доставка приложений через веб-браузер с поддержкой HTML 5 - то есть, открыл браузер - а там каталог приложений, выбираешь - и приложение открывается как будто установленное).
Выглядит это очень похоже на Dropbox:
Что касается модели потребления услуг VMware Octopus, то, как рассказала VMware, это решение можно развернуть как в датацентре своей организации, так и воспользоваться услугами сервис-провайдеров, предоставляющих услуги по программе VSPP.
Надо отметить, что свободной регистрации для использования продукта пока нет, но можно запросить доступ к preview-версии на сайте www.vmwareoctopus.com.
В первой части статьи "Сравнение производительности StarWind iSCSI Enterprise и Microsoft iSCSI" мы приводили выводы Джейка Ратски о том, что iSCSI-таргет от компании StarWind показывает большую производительность по сравнению с его аналогом от Microsoft для рассмотренной нагрузки при установке одной ВМ. Теперь Джейк провел тестирование обоих продуктов при использовании трех виртуальных машин (на той же самой конфигурации оборудования), с которым можно ознакомиться в следующих статьях:
Для тех, кто использует хранилища iSCSI под виртуальные машины - очень полезно ознакомиться. Приведем основные выводы.
1. Использование полосы пропускания адаптера iSCSI.
Microsoft iSCSI:
StarWind iSCSI:
Как видно из картинок, StarWind iSCSI потихоньку разгоняется и показывает лучшие результаты, чем Microsoft iSCSI Target. Происходит это за счет активного использования кэша на сервере хранилища iSCSI, как и в предыдущем тесте:
2. Эффективность процесса дедупликации.
Как мы уже писали, StarWind iSCSI использует inline-дедупликацию данных на хранилище с размером блока 4 КБ, что подразумевает запись на диск только оригинальных копий данных, без повторяющихся блоков. В тесте для 3-х ВМ размером 9 ГБ каждая на хранилище было реально занято 8,69 ГБ данных, что довольно эффективно для трех практически одинаковых машин.
Коэффициент дедупликации - 3.15 к 1.
3. Производительность хранилища.
В тесте опять использовалась нагрузка, генерируемая IOMeter, на одной машине при двух простаивающих, а также на всех трех одновременно. Результат MS iSCSI (нагружена только одна ВМ):
Результат StarWind iSCSI:
И тут снова StarWind выигрывает.
Теперь метрики IOMeter для трех одновременно нагруженных ВМ для Microsoft iSCSI (минута с момента начала генерации нагрузки):
Компания StarWind продолжает развивать партнерскую сеть и развиваться сама:
Компания Systematika недавно присоединилась к партнерской сети StarWind Global Distribution Network
Берлингтон, штат Массачусетс – 19 марта, 2012 - StarWind Software Inc., разработчик инновационного программного обеспечения для построения СХД и резервного копирования виртуальных машин, сегодня объявила о присоединении компании Systematika Distribution к международной партнерской сети StarWind. Компания Systematika, которая в Италии является лидером среди дистрибьюторов в области виртуальных технологий, добавила в свое портфолио программные продукты от StarWind. Теперь программное обеспечение StarWind будет распространяться через обширную сеть торговых представителей Systematika на эксклюзивной основе.
"Компания StarWind пополнила наше портфолио высококачественными и доступными по цене решениями СХД. Продукты этой компании представляют идеальное сочетание производительности, простоты и функциональности, и обеспечивают превосходную защиту данных. Мы думаем, что эти качества будут чрезвычайно интересными и выгодными для наших клиентов. Мы рассчитываем на длительное и успешное сотрудничество", - говорит Франко Пуричелли (Franco Puricelli), менеджер по продажам и развитию бизнеса компании Systematika Distribution.
"Мы очень рады сотрудничеству с Systematika Distribution, признанным лидером рынка виртуализации в Италии. Ведь правильный подбор партнеров очень важен для нашего бизнеса", - говорит Артем Берман, генеральный директор компании StarWind Software. "Мы уверены, что наши продукты будут иметь успех у клиентов Systematika, особенно в секторе малого и среднего бизнеса. Это однозначно поспособствует укреплению наших позиций на рынке".
Продолжаем вас знакомить с решением номер 1 для создания отказоустойчивых хранилищ виртуальных машин для серверов VMware vSphere 5 - StarWind iSCSI Enterprise. Блоггер Jake Rutski провел интересное тестирование, в котором он сравнил производительность продуктов StarWind iSCSI Enterprise и Microsoft iSCSI при работе виртуальных машин с хранилищами. Итак, характеристика тестового окружения...
Если вам хочется поддержать компанию StarWind Software, выпускающую лучшие решения для создания отказоустойчивых кластеров хранилищ VMware vSphere и Microsoft Hyper-V, номинируйте ее продукты на сайте премии Storage Awards 2012:
Наши друзья из Киева будут очень вам благодарны, если вы укажете продукты StarWind iSCSI SAN или StarWind Native SAN for Hyper-V в следующих категориях (в других не надо):
"Storage Virtualization Product of the Year"
"Storage Product of the Year"
"Storage Company of the Year"
Чтобы узнать, чем хороши приведенные выше продукты, можно почитать следующие статьи:
Решение номер 1 - StarWind iSCSI SAN - для создания отказоустойчивых хранищ под виртуальные машины серверов VMware ESXi и Microsoft Hyper-V снова в продаже со скидками, которые уменьшаются каждый день. Торопитесь!
Календарь скидок в процентах при заказе в первых двух неделях марта:
Как вы знаете, в VMware vSphere 5 есть возможность динамической миграции хранилищ виртуальных машин - Storage vMotion. Эта возможность позволяет не только без простоя перенести виртуальные машины между хранилищами и их LUN, но и изменять формат результирующего виртуального диска (thin или thick).
В этой заметке мы рассмотрим один из интересных аспектов миграции Storage vMotion - перенесение томов RDM (Raw Device Mapping) виртуальных машин, работающих в режиме виртуальной и физической совместимости (physical and virtual RDMs).
Также перенос хранилища виртуальной машины мы можем сделать не только в "горячем" режиме, но и в "холодном" с помощью функции Cold Migration (для выключенной ВМ). В этом случае мы также можем выбрать формат виртуального диска результирующей ВМ. Давайте посмотрим как эти условия влияют на перенос RDM томов во всех случаях.
Перенос включенных ВМ с физическим RDM (pRDM) средствами Storage vMotion:
Если вы пытаетесь изменить формат результирующего диска - Storage vMotion будет сделать нельзя.
Если вы не пытаетесь изменить формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос включенных ВМ с виртуальным RDM (vRDM) средствами Storage vMotion:
Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос выключенных ВМ с физическим RDM (pRDM) средствами Cold Migration:
Если вы изменяете формат результирующего диска (в advanced view) - том pRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос выключенных ВМ с виртуальным RDM (vRDM) средствами Cold Migration:
Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Таким образом, у нас получается 3 ситуации, когда исходный RDM-том конвертируется в VMDK-диск на целевом томе, при этом в мастере миграции вас никто об этом не предупреждает.
Также есть еще один аспект при миграции таких томов. Если исходный RDM-том находился в режиме Independent Persistent (а pRDM обязательно в этом режиме находится), то, как следует из свойств этого диска, он не участвует в создании снапшотов ВМ.
После миграции, если он будет сконвертирован в vmdk-файл, то он также останется в этом режиме:
А это значит софт для резервного копирования виртуальных машин не будет бэкапить такой диск, поскольку он не участвует в создании снапшота. Учитывайте этот момент.
Продолжаем втягивать вас в процесс ознакомления с решением номер 1 StarWind Enterprise iSCSI для создания отказоустойчивых хранилищ виртуальных машин Microsoft Hyper-V и VMware vSphere. На этот раз несколько новостей о продукте StarWind Native SAN for Hyper-V (с резервным копированием StarWind Hyper-V backup Plug-in), который позволяет используя всего 2 сервера, сделать кластер из серверов Hyper-V и сделать хранилища прямо на этих серверах, которые продолжат непрерывно работать в случае отказа любого из них.
Во-первых, приходите сегодня на вебинар Толи Вильчинского, который быстро и четко говорит по-английски, но (наверняка) сможет ответить на ваши вопросы по-русски:
Компания StarWind, выпускающая продукт номер 1 StarWind iSCSI Target для создания отказоустойчивой инфраструктуры хранилищ для виртуальных машин vSphere и Hyper-V, продолжает информировать вас о своем новом продукте для резервного копирования виртуальных машин StarWind Hyper-V backup Plug-in, который поставляется как плагин к основному решению.
Напоминаю, что StarWind Hyper-V backup Plug-in это:
Безагентная Архитектура
Резервные копии, сохраняемые в «родном» для Hyper-V VHD-формате
Глобальная Дедупликация
Операция резервного копирования в один клик
Обращаю также внимание, что мероприятие пройдет 9 февраля в 17-00 по москве, то есть послезавтра - поэтому не задерживайтесь и приходите вовремя. Подробнее о плагине StarWind Hyper-V backup Plug-in для резервного копирования виртуальных машин Hyper-V и ESX/ESXi можно почитать в нашей заметке.
Как раз в тему - у StarWind до 15 февраля есть возможность приобрести плагин для резервного копирования ВМ Hyper-V на 15% дешевле от будущей цены. Покупайте сейчас, чтобы через 2 недели не платить больше.
Плагин Hyper-V Backup Plug-in включает в себя:
Безагентную архитектуру
Дедупликацию хранимых резервных копий
Хранение бэкапов в формате VHD
Резервное копирование в один клик
Тестирование резервных копий на целостность
Подробнее о продукте Hyper-V Backup Plug-in можно узнать тут и тут, а оформить заявку можно на сайте StarWind по этой ссылке.
Мы уже писали о том, что в новом продукте StarWind Native SAN for Hyper-V для создания отказоустойчивых хранилищ Hyper-V с использованием всего 2-х серверов присутствует возможность резервного копирования виртуальных машин под названием VM Backup. Давайте заглянем немного в процесс резервного копирования StarWind Native SAN. В плане работы с плагином VM Backup сначала появляются следующие задачи:
Более-менее стали оформляться подробности о новой файловой системе ReFS (Resilient File System), которую компания Microsoft планируют ввести в новых версиях Windows 8 (серверной и клиентской). Первоначально ReFS будет включена в состав серверной версии нового семейства ОС, а только затем в десктопную версию и далее появится возможность использования ее для загрузочных разделов (цикл внедрения аналогичен NTFS, который применялся в свое время).
Основная идея ReFS - дополнительные функции отказоустойчивости, которые будут обеспечиваться средствами "эластичной" обработки программных и аппаратных ошибок.
Что касается изменений ReFS по отношению к максимумам NTFS - их почти нет (за исключением удвоения максимального количества файлов в каталоге и увеличения размера тома):
Самый потенциально неприятный момент - в ReFS нельзя будет конвертировать существующие тома NTFS, поэтому данные придется переносить простым копированием.
Кроме того, в Windows 8 Server система ReFS в перспективе будет обеспечивать функции виртуализации хранилищ (пространства хранения - storage spaces).
Первоначально планируется, что Storage Spaces будут работать для томов NTFS, позволяя гибко агрегировать физические дисковые носители в пулы ("пространства"), которые организованы с помощью техник зеркалирования и контроля четности (mirror - частое обновление, например, документы и parity - частое чтение, редкое обновление, например, фотки и видео). При этом утверждают, что это не обычные RAID-тома (но диски в пространствах по отдельности читаться не будут). Пространства будут также поддерживать технику Thin provisioning, которая позволит создавать их размером, например, в 10 ТБ, при этом "под ними" может быть гораздо меньше сырой емкости:
То есть, при нехватке физического пространства будет выдаваться предупреждение о том, что необходимо добавить еще сырой емкости в пул.
В целом и ReFS, и пространства хранения - какие-то не очень нужные, как кажется, вещи. Пространства хранения выглядят просто как приучение пользователя к созданию избыточных хранилищ данных. Больше деталей обещают к концу февраля, поскольку на это время намечен выход бета-версии клиентской Windows 8. Окончательный же выход новой платформы ожидается к концу года (серверной и клиентской).
Многие из вас уже читали о новой версии StarWind Enterprise 5.8 для организации отказоустойчивых ISCSI-хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Одна из интересных фич новой версии - возможность резервного копирования хранилищ виртуальных машин, идущая как плагин к продукту (VM Backup). Бэкап работает как для vSphere, так и для Hyper-V (с поддержкой дедупликации).
В связи в этим обновилось сравнение изданий продукта для платформ VMware и Microsoft.
Издания StarWind iSCSI SAN (для серверов ESX / ESXi):
Возможности
StarWind
Enterprise CDP Edition
StarWind iSCSI SAN
1TB
2TB
4TB
8TB
16TB
Unlimited
Support
1 year
1 year
1 year
1 year
1 year
1 year
1 year
# of Servers per license
1
2
2
2
2
4
(2 HA sets)
4
(2 HA sets)
Maximum Capacity
Unlimited
1TB
2TB
4TB
8TB
16TB
Unlimited
# of Concurrent iSCSI Connections
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Ethernet ports
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Served Disk Drives
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Synchronous Mirroring (Active-Active High Availability)
Remote Replication (Active-Passive)
Automatic Failover
Failback with Fast Synchronization
Disk Bridge
SPTI
Image File
IPSec, CHAP, ACL, iSNS
CDP / Snapshots
Thin Provisioning
High Speed Caching
Event Log
Event notifications
Deduplication
*VM Backup Option
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
Издания StarWind Native SAN for Hyper-V:
Возможности
StarWind Native SAN for Hyper-V
1TB
2TB
4TB
8TB
16TB
Unlimited
Support
1 year
1 year
1 year
1 year
1 year
1 year
# of Servers per license
2
2
2
2
2
2
Maximum Capacity
1TB
2TB
4TB
8TB
16TB
Unlimited
# of Concurrent iSCSI Connections
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Ethernet ports
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Served Disk Drives
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Synchronous Mirroring (Active-Active High Availability)
Remote Replication (Active-Passive)
Automatic Failover
Failback with Fast Synchronization
Disk Bridge
SPTI
Image File
IPSec, CHAP, ACL, iSNS
CDP / Snapshots
Thin Provisioning
High Speed Caching
Event Log
Event notifications
Deduplication
*VM Backup Option
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
Стоимость VM Backup Option указана за физический сервер ESX или Hyper-V, виртуальные машины которого вы планируете бэкапить. При этом неважно количество процессоров и ВМ на данном сервере.
Как мы недавно писали, новая версия продукта номер 1 для создания iSCSI-хранилищ виртуальных машин vSphere и Hyper-V - StarWind Enterprise 5.8 уже доступна для загрузки. Одна из самых полезных новых возможностей версии StarWind 5.8 для Hyper-V - это функция VM Backup, предназначенная для резервного копирования виртуальных машин.
На сайте steelbytes.com недавно обновилась бесплатная утилита HD_Speed, которая позволит вам протестировать производительность дисков в виртуальных машинах VMware vSphere или на других платформах.
Утилита выводит статистику скорости обмена в реальном времени не только для виртуальных дисков, но и любых других устройств - hard disks, cd/dvd-roms, flash cards/sticks, floppys и т.д. Поддерживаемые режимы - чтение, запись, чтение-запись, чтение-запись-проверка (можно задавать размер блока). С режимом записи осторожнее - можно уничтожить данные на диске. Также возможно тестирование пиковой пропускной способности устройства.
Результаты можно писать в лог-файл. Что приятно - присутствует интерфейс на русском языке.
* Внимание! Цены указаны по курсу доллара ЦБ РФ на 29.11.2011. При покупке уточняйте стоимость у менеджера Softline.
Все системы хранения NetApp обеспечиваются трехлетней гарантией. Гарантия включает в себя сервис по замене вышедших из строя частей с доставкой по месту установки системы хранения на следующей рабочий день.
Надо сказать, что NetApp делает крутяцкие массивы, которые хорошо интегрированы с технологиями виртуализации VMware (см. тут, тут и тут). Кроме того, массивы NetApp обеспечивают поддержку технологии VAAI, которая во многих случаях в разы увеличивает производительность хранилищ виртуальных машин.
Получить консультацию и приобрести дисковые массивы NetApp вам поможет Роман Карнаухов (e-mail: netapp@softline.ru, тел. +7 (495) 232-0023, доб. 0959).
Наконец-то хоть кто-то сделал (или я только узнал) человеческую утилиту для добавления custom-драйверов в дистрибутив (ISO) сервера VMware ESXi 5. На сайте v-front обнаружилось средство ESXi-Customizer:
Утилита ESXi Customizer полностью бесплатна и имеет GUI под Windows, однако, отметим, что такой способ вставки драйверов в дистрибутив ESXi не поддерживается со стороны VMware. Во время получения финального ISO-образа ESXi вы можете прервать процесс и поменять различные параметры целевого образа (в текстовом фале):
Скачать утилиту ESXi-Customizer можно по этой ссылке. Также по теме будет интересна вот эта статья.
Да-да, это не опечатка - 20% и менее. Компания StarWind Software, поставщик продукта номер 1 - StarWind Enterprise - для создания отказоустойчивых хранилищ iSCSI виртуальных машин VMware vSphere и Microsoft Hyper-V, объявила о начале рождественской распродажи лицензий на ПО:
Смотрите, штука такая - 16 декабря назначается скидка на покупку ПО StarWind Enterprise в 20%. Далее каждый день она уменьшается на 1% и 26 декабря заканчивается на отметке в 10%:
Правда сильная маркетинговая штука? Акция действует и для России (инфа 100%). Поэтому, если вы планировали купить StarWind Enterprise в редакциях HA или CDP - бегите быстрее к вашему поставщику и хватайте скидки (можете обратиться, например, к нам).
О новых возможностях StarWind Enterprise 5.7 и 5.8 можно почитать тут и тут, соответственно. О том, для чего нужен продукт - читайте здесь.
Таги: StarWind, Enterprise, VMC, HA, Storage, iSCSI
Помните, мы писали, что снапшоты виртуальных машин в VMware vSphere - это плохо? Но иногда без них не обойтись - например, системы резервного копирования (например, Veeam Backup and Replication) вынуждены делать снапшоты, чтобы не прерывать работу виртуальной машины во время бэкапа.
Цель этой заметки - показать, что в VMware vSphere при работе со снапшотами все сделали несколько лучше, чем в предыдущей версии. Во-первых, смотрим это видео:
Мысль видео такова: если у вас некорректно завершилась операция по консолидации снапшотов, то в VMware vSphere 5 вам предлагается опция по консолидации, доступная из контекстного меню виртуальной машины:
То есть, теперь не надо терзать командную строку в случае появления проблем со снапшотами виртуальных машин.
Во-вторых, появилась опция по поиску виртуальных машин, нуждающихся в консолидации снапшотов, доступная из vSphere Client. Чтобы найти такие машины, нужно выбрать хост или кластер, перейти на вкладку "Virtual Machines" и по правой кнопке выбрать пункт "Needs Consolidation":
Ну и, в-третьих, в vSphere 5 полностью поддерживается "горячее" перемещение виртуальных машин между хранилищами средствами Storage vMotion, а также, само собой, между хостами средствами обычного vMotion.
На сайте проекта VMware Labs, где в последнее время часто появляются полезные утилиты от сотрудников VMware, опубликована новая штучка - VMware I/O Analyzer, виртуальный модуль (Virtual Appliance) для анализа статистики по вводу-выводу.
Данное ПО включает в себя стандартные средства для измерения производительности систем хранения VMware vSphere, которые позволят выявить проблемы и узкие места в инфраструктуре хранилищ.
Ключевые возможности VMware I/O Analyzer:
Интегрированный фрейворк для тестирования хранилищ
Готовый к развертыванию виртуальный модуль
Прост в настройке и возможность исполнения тестов на нескольких хостах ESX/ESXi
Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС
Возможность экспорта данных для последующего анализа
Скачать VMware I/O Analyzer можно по этой ссылке. Инструкция по развертыванию доступна тут.